Talk:Change log
As of today, this page is only a sample - to be developped and extended according to community discussion below. The principle is to list changes from v18.2 to v1.19 as found in the game files. The 'Game files' column is a reminder of this and is therefore checked for all items. The 'In game' column is there to indicate that the change was actually implemented (can be seen in game). Indeed, some changes are brought to the game files as developers work but are not brought on-line. Waiting for your comments before going any further. --Lirielle 17:22, 8 July 2007 (UTC) =Suggestion= Instead of check marks, the 'In game' column could carry the date when the changed was confirmed as on-line. --Lirielle 17:31, 8 July 2007 (UTC) :I was thinking in a easier name, like "Update 1.19.0" or "Version 1.19.0" or "Ver 1.19.0" or even shorter "1.19.0" as like the idea of typing Change log/1.19 rather odd. : Also the actual table, the term of "in game files" its rather redundant as this pages will be build in base of game files dont they? : This page will cover the changes so that will also look odd but will have to test styles thought in my proposition in the forum was to create a like log page where all the changes done to the game (if its necessary something to distinguish what is in game and the rest well obvious game files. Also that page may cover details specific to that version covering like the announced changes etc. Then there would be a 2nd unique page (only one page no subpages) where all this changes and additions from the different version pages will be display (yah maybe it will be a little to big) that way we will not miss the older changes and will advance more progressively, in that 2nd page where will be no version distinctions only new and change distinguishing with minor subsections like "changes -> monsters/npc/etc" and "new -> monsters/npc/etc" this page will be take to the project name space : I would recommend using the separate versions ".0", ".2" etc because sometimes they do excessive changes in the in between changes and that would buff a lot certain pages where there are various version like 15 has 1 update, 16 has 3 updates, 17 has 1 update, 18 has 2 updates. And that is counting official not test ones. : I can build some draft pages, but i would require that we decide on what to do with the name to choose : --Cizagna (Talk) 19:45, 8 July 2007 (UTC) ::Thx for taking the time to answer. Yes the Game files column is dispensable. I've inserted it for two reasons: 1) to make it clear where the info comes from (found in game files, to be confirmed on line) and 2) to have a parallel layout to the interim updates, which work backwards (found on line, to be confirmed in files). While it is not absolutely necessary, it is usefulness is thus subject to debate. ::For the naming aspect, you're back with your disliking of subpages, which I don't quite understand. They are successfully used in some other parts of the wikia and bring in some hierarchy and navigation ease that I find useful. I can't think of these pages being searched for under the names you mention nor under any other name except maybe the release number, but rather via a link to the parent page (Change log) on the wikia's Main Page. ::I'm afraid I can't make out what you mean in your third paragraph unless you rephrase it. What is sure, is that we need to put successive updates on separate pages lest these pages grow larger that reasonable. ::Whether you call the main release 1.19 or 1.19.0 doesn't matter, I never suggested to leave out secondary updates. ::--Lirielle 21:26, 8 July 2007 (UTC) : Where the info comes can be stated on the central article but thats a chat for later. : About the names i see hard to look for "change log" (in fact the first time i saw the word "log" been use to keep track of the updates was at the dofus forum "note log" and even thought i may agree that "change" is the proper english word its not of common sense when games is related as a digital thing every change is normally tied up with the word "update", i always look for the word "update" when im browsing a page looking for changes ( "update", "update information", etc), i would discard "version" or "Ver" those were just redundant alternatives and the one with only numbers its just for been lazy at doing links like 1.19.0 so then i dont have to worry about the word update (but i would fall in the same tendency as what im debating). and why the 0 because with out it implies that has all the 19 update rather than just the .0 : About subpages, well i learn to hate them as i worked with the community portal and my user page they are annoying for linking outside of the central article page and are not flexible the only place that is great for them is in the original page (god redundancy). Also in certain linkings im force to style the link due to the "/" I aggree with wikipedia "Subpages were originally used on Wikipedia to differentiate between subjects to create topical hierarchies of articles, but this proved unworkable because articles tend to belong in more than one hierarchy." if you like subpages i can create a separate parent template to be use and i even can add them they can be more effective and customize than the one its automatic. About been use in other parts, yes its been use mostly in the class specific pages (and with those weird names thank god at least i know what class they are talking about), in the specific profession pages, and other pages like your ethereal list or places where Dashiva store raw data and when you search for that you are force to put that "/" if you want to be directed automatically other way you have to do extra hand movement and then click : About the 3er parragraft every box below is a page, info below its not real. Update 1.18.2 ---- Anakma announcement *Cut to the point update inforamtion. Changes NPC *Ganymede -> Gunpowder Monster *White Gobball -> White Gobbly ETC *etc New NPC *Ganymede Klawot Monster *Emerald ruby ETC *etc Update 1.19.0 ---- Anakma announcement Cut to the point update inforamtion. Changes NPC *Granny -> Groovy Monster *Tofu -> Tafu ETC *etc New NPC *Lolipop Monster *Minowow ETC *etc Dofus:Update (or Current or ToDo i know know there are multiple names) ---- Changes NPC *Ganymede -> Gunpowder *Granny -> Groovy Monster *White Gobball -> White Gobbly *Tofu -> Tafu ETC *etc New NPC *Ganymede Klawot *Lolipop Monster *Emerald ruby *Minowow ETC *etc OK, never mind the subpages, we can use links to full pages, I don't care. I'm glad that you agree to put each release on a separate page ;). Now to the next point: hierarchy. There are two ways to organize the items on a log change. We have examples of both in my user pages ;). One is to make two main sections: New and Changed, then subsections for items, monsters, npcs, etc. Another way, which I prefer, is to have main sections for Items, Monsters, NPCs, Areas, etc. and subsections for new, name change, price change, etc. Also, another point that I would like to solve are the interim changes; ie. those changes that are brought on line between two official releases. I can think of two approaches: # make 1 page for 1.19.0, one page for interim changes, 1 page for 1.19.1, etc. # make an additional "latest changes" page with the interim changes and move them to the page for the next release when the latter is published. I was going for solution 1, but solution 2 will be more effective. As interim changes get integrated in the newest release, so are our pages. Also, maintaining separate pages will make comparisons more difficult. --Lirielle 21:49, 13 July 2007 (UTC) :Hierarchy i prefer new with new, changes with changes and remove with remove its more to the point and you will not have to browse all the topics to look for changes mixed with the new items or the removed ones, its not visualy attractive to be jumping between a series of same tables like the ones you want to use for the new ones will contrast with the ones for changes and the simplicity for the removed ones. :Interim changes let me think about it as im still trying to solve the information of "officially announce" and "unofficial/gathered changes"--Cizagna (Talk) 03:33, 14 July 2007 (UTC) Note For the following discussion, I'm using the following terminology: * static game files: .SWF flash files delivered with a new official release, found in the Dofus install directory * dynamic game files: .SOL flash files updated each time you connect to Dofus, found in the Macromedia directories under your user's Application Data folder About interim changes I've been thinking about them. There are different cases to consider: * changes are made to the static game files but not brought on-line :Example 1. The game files delivered with 1.18.2 had many NPCs and quests that were only released with 1.19 :Example 2. Future sets are in the static game files and are being maintained there * changes are brought on-line but are not reflected in the static game files :eg. The new Sponge Set is implemented, but the individual items are not found in the static game files. ;What are we recording here? When I first started building change logs in my user pages, all changes were based on a comparison between static game files of two successive releases. As can be seen eg. in User:Lirielle/NewIn19, I was quickly faced with the abovementioned issues of discrepancies between the static game files and the on-line releases. Hence the question of what to do with 'interim changes'. I think it's time to reconsider whether the change logs we are building now should be based on the static games files or should include any change brought on-line (quickly reflected in the dynamic game files). One major difference would be that we have currently no tools to compare successive versions of the dynamic game files. IOW, it all depends on what the users discover either on line or arbitrarily in the dynamic files. So far, because of the current approach based on the static games files, I have considered two ways of recording 'interim changes': either on a separate page of their own, or temporarily on a 'latest changes' page before moving them to the new release page when the time comes. I am now considering a different approach. That is: all changes brought on line before the next release belong to the current release. As the example of the Sponge Set demonstrates, this approach matches the reality. Therefore, I suggest we record on the 1.19.0 page : * all(?) changes between static files of 1.18.2 and 1.19.0 * all changes observed in 1.19.0 before the next release Of course, there would be some overlap (changes observed on line in 1.19.0 will appear in the static files for 1.19.1). Consider the following: * change comparison between static files is technically easier and are exhaustive * for easier maintenance, it's more efficient to list all such changes and mark them as appropriate rather than selectively list the changes that have not been brought on line earlier. * better an overlap than gaps ;) I'd therefore suggest that we add such columns as are necessary to efficiently track when and where changes occur. When we finish building the change log for 1.19, we should have listed all particular cases and designed a solution to manage them. Let's take an example: ;v1.18.2 (May 16, 2007) * Item1, Item2, Item3, Item4, Item5 are introduced in the static game files * Item1 is implemented in this new version and immediately noticed * Item2 is implemented in this new version but only observed in game a few days later * Item3, Item4, and Item5 are not implemented Change log for 1.18.2 ;Changes to 1.18.2 (June 10, before the release of 1.19) * Item3 gets implemented -> Date observed is added to the Confirmed column * Item6 is added Change log for 1.18.2 ;Release of 1.19 * Item4 still not implemented * Item5 is now implemented, but under a new name (Item5new) * Item6 now appears in static game files * Item7 and Item8 are added Change log for 1.18.2 Unless a change never gets implemented, older change logs thus continue to evolve until the last column only shows "True" checkmarks. Change log for 1.19 :Its nice but looks hard to maintain. :"Check marks" well you are using wikilinks that its enoughs for check marks for new items we can know if it exists on the wiki or dont dont we?. :"Observation date" that would make it also very hard, then you will have to create a team of trust people for checking those sort of things sort of every time the server shuts down. Because one person is simply to much. :This pages are going to be harmonizing with another page that was the announcements of amakna so this information should start separating also. :Now lets go 1 step at the time that you are going maybe a little to fast # Do you already have archives of the .sol files to make a comparative? ## if yes since what version? :Now i have saved static game info since 1.15.4 and i think i have found an older installation file. So thats a lot of work that i will have to do so "interim game info" not my priority in what this update pages concerns. :If your archive of soles has certain versions back the advantage will be that we may obtain a pattern on the update numbers so we may be able to give it specific .# sequence but for that i guess we will have to do first by dates and then as we see just try to correct that as the update information starts developing. :One important thing is conclude the old before we can start on the new stuff, other way this section will keep haunting us :--Cizagna (Talk) 00:48, 15 July 2007 (UTC) ::Yup, it's kinda complex. It has too be if we want to be accurate. But we can decide to be less accurate ;) ::"Check marks:" links suffice for such things as new pages, not for the rest. Checking a name change implies that we updated all links etc. Implementing a stats doesn't change the link status, and we can't go the corresponding page every time we want to confirm that the change was made. ::"Observation date" is (was) not meant to be the implementation date. IOW, it would have been the "date first observed" with some delay from the actual implementation date. ::.SOL files: re-read my text: we currently have no tool to do the comparison. We'd need a flash programmer like Fogleg, but he hasn't showed up since I wanted to ask him. ::I've finished listing the changes. To make it simpler and at the same time allow us to better track the changes, I'll be restoring the 'source' column to indicate whether the info comes from swf or sol files. The main issue if we go that simpler way lies with the unimplemented changes (like the Bwork quests and NPCs in 1.18.3). When we start creating the change log based on the game files, we'll have to look back on the change log for the previous release to see what has not been checked and add it to the new change log does that make sense? ::I'll change the page again along these lines. ::Also, I need to find back and add the latest changes ('interim changes' from 1.19.2) ::--Lirielle 07:56, 15 July 2007 (UTC) ::: Btw the first link on the page to astrub rocky inlet, is wrong... its links like this Astrub Rocky InletWith. Dont think thats right somehow :P. --Kiriath(Talk) 10:52, 15 July 2007 (UTC) Latest Layout Notes OK, I think its getting close to the final layout ;). To make things simpler, I dropped the formal idea of noting swf versions and on-line observation dates. #As the change log now is a mix of swf-based changes AND changes brought on-line after the release (thus not reflected in the swf files), I've also reinstated the 'source' column, where we record whether the change is to be found in the swf files or only on-line (SOL file, which reflects on-line changes shortly after). When a change was already present in the previous release, but not implemented, we can optionally mention the swf version between brackets. #The fact that a change is logged in the swf file or that we applied it to the wikia doesn't mean that said change is actually implememented in the game (eg. the Megaman set items). Even changes found in the sol file may be under development only and not implemented. So I kept the column confirming that the change has been observed on-line. To avoid the complexity of dates, it's just a True/False field. #About Changes (vs. New), I grouped all changes for a category (eg. Items) under two tables: Name changes and Other changes. As the tables are alphabetically sorted, this helps grouping changes affecting the same entry. #Finally, to cover all situations eg. sth still not implemented, I added a Note column where we can drop any relevant comment. Eg. 'Not sure whether this is implemented' or 'Now implemented, but name has changed'. A user could mark a NPC as observed 'on-line' and add the coords for it in the Note column if the corresponding page has not been created yet, etc. #When this discussion is over, we need to state the rules on the main 'Change log' page (with a link on top of each individual release page), but I think the layout as currently designed is rather straightforward (except for an explanation on what swf and sol files are, but the average user won't use this column). Except for a few tables that still need be reformatted, I think the page is complete and I'm awaiting your comments. --Lirielle 12:05, 15 July 2007 (UTC) :I think you want to use this page as a log page where to keep some sort of the progress... and thats not the idea the idea is to tell what the update contains, in certain easy and simple to read (and in our case as editors barely to maintain just to add stuff we may be missing). :if the item is or not available can be done by some tag or color mark. as when the page gets created will have any way the unavailable template and its will just informative that in X update was this item discover but it was known that it was unavailable and by X will have the version and in the version page has the date. :Until we know how to get those SOL files the source is irrelevant (and will only be relevant to the actual one what do we do with the other versions going back to 1.15?) as all the info is from the SWF files. :Our log book is different from the version pages, all that information can be there with out any issue as the information gets ended it gets remove from our log page. :if its on wikia the link will be availeble if its not on wikia the link will not be availeble if its half way in the wikia then it will be a link present in our project log page of pending things of the update. :Example the astrowig, we know its a unavailable item, that its on the wikia, in any case old and new values seems like tedious to reflect unless you are planing users to contribute with us and for that we will manage in "our" log page. :I like the page and the layout but you are mixing technical information (that its project related) with information that its purpose of creation its just informative (and harder to maintain as we will be updating our log book, and then will be have to come here and update it also making it tedious --Cizagna (Talk) 18:36, 16 July 2007 (UTC)